Repository navigation
test(Lightbox): the busy zoom proof judges the photo's top edge - #10648
Conversation
The double-tap zoom's busy proof read the photo's height. The height adds two edges' whole-pixel steps, so near the end a frame can show no new height while each edge still moves almost a pixel. The proof's step rules read one coordinate's travel, so they took that plateau for a stall. Reading the top edge gives them its own travel. The proof stops 24 px of the edge from rest, where its move between two cast frames falls under one cast step: Chromium casts every frame in 1 px steps, and blocked WebKit casts every 116 ms or more in 2 px steps.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
meta-cla
Bot
added
the
CLA Signed
|
AI review status for this pull request.
|
PR Analysis Report
Generated by PR Enrichment workflow | View current CI run |
Besides the verdict, the double-tap zoom's busy proof now asserts what it judges: the photo's top edge takes a new position on every frame the control moves, with no frame excused as under a cast step, and the control moves on at least the verdict's floor of four frames.
![astracat-bot[bot]](https://avatars.githubusercontent.com/in/4796231?s=60&v=4){kind=small}
There was a problem hiding this comment.
Approved pending CI: CI has not run on this head yet, because the pull request is a draft on a fork branch. Once it is marked ready for review, a maintainer adds the ci:run label so CI runs the interaction proofs in Chromium and WebKit.
Judging the photo's top edge with a 24 px settle bound keeps the proof's intent. The photo must still move on every frame the compositor control moves, and the main-thread and frozen controls still fail. The new bound stops judging before the first frame where whole-pixel rounding holds the edge still, so those holds no longer read as stalls.
[Automated review]
There was a problem hiding this comment.
Approved pending CI: CI has not run on this head yet, because the pull request is a draft on a fork branch. Once it is marked ready for review, a maintainer adds the ci:run label (it takes effect on the next push) so CI runs the interaction proofs in Chromium and WebKit.
The spelled-out assertions keep the proof's intent: the photo must take a new position on every frame the compositor control moves, and the main-thread and frozen controls still fail.
- Miss: a non-blocking fix, since near the end this zoom moves about 0.032 of what remains each frame, not 0.042, so Chromium's per-frame move drops under 1 px about 30.5 px from rest rather than 23.9 px (comment above
ZOOM_SETTLED_PX), which leaves the newbelowStepassertion one frame of slack before a held frame enters the judged part; a 32 px bound gives it real margin (measured from the photo's rest, it also stops depending on when the screencast stops), and the comment's numbers need correcting either way.
[Automated review]
| * step. Near the end, each 60 Hz frame moves the spring about 0.042 of what | ||
| * remains (2π / 2.5 s, critically damped). Chromium casts every frame in 1 px | ||
| * steps, so its moves fall under a step 23.9 px from the end. Blocked, WebKit |
There was a problem hiding this comment.
Non-blocking. For a critically damped spring from rest, what remains is A(1 + ωt)e^(-ωt), so a frame moves ωΔt · ωt/(1 + ωt) of it. That is about 0.032 at 24 px, not 0.042, which is the rate only as t grows without bound. The recorded top edge fits that curve to within 5 px in total. The move drops under 1 px at about 30.5 px from rest. The last ~4 judged frames move 0.86–0.98 px. In every run here, rounding still shows a new position on each of them, and the first held frame (y = 25) comes one frame after the cut. With expect(proof.control?.belowStep).toBe(0) that one frame is the whole margin. Replaying the same runs with the cast ending at rest (y = 0) fails the new assertion while the verdict passes. A 32 px bound, or settledAt read at rest, keeps belowStep 0 and still judges about 1.3 s.
cixzhang
added
the
ci:run
The double-tap zoom's busy proof reads the photo's top edge and spells out its per-frame check: vjeux/astryx@619ffeb...569ba49
Maintainer impact
"the double-tap zoom keeps advancing every frame while the main thread is blocked" fails in Chromium with "moved on 94 of the 95 frames the control moved": on #10622, #10571 and #10588 (line 990, before the paging).
Intended invariant
The photo still moves on every frame the compositor control moves, on the same four-frame floor; a main-thread or frozen zoom still fails. The stall rule is stricter: the sub-step run allowance no longer applies.
Change
The proof reads the top edge and stops 24 px from rest, where the edge's move between two cast frames falls under one cast step. At tempo 5 a 60 Hz frame moves it about 0.042 of what remains, so Chromium's 1 px casts of every frame fall under a step from 23.9 px. Blocked, WebKit casts every 116 ms or more in 2 px steps, so only from about 8 px; its judged part is unchanged.
Evidence
The four conditions:
minProgressMsfix. Two replayed runs show such lags.Scope
Testing
Core
tsc, ESLint and Prettier are clean. The runs use a 4-CPU container (--cpus=4), with six spinning threads beside the browser for the loaded profile, and one Storybook build of main 372f681 for both arms. A replay feeds each run's recorded frames (the photo's top edge and height, the control's position) to the harness'sbusyWindowProof. From the height it reproduces all 50 recorded Chromium verdicts. From the top edge, CI's failing run and 38 of 40 loaded runs pass, and its 16 recorded WebKit verdicts are unchanged.